09. Loop 与 Agent 执行循环

版本：v1.0

最后更新：2026-07-02

说明：本文中的 loop 默认指 AI Agent / LLM 应用中的执行循环（agent loop / execution loop），不是通用编程语言里的 for / while 语法。

1. 什么是 Loop

在 Agent 系统里，loop 指的是系统为了完成一个目标，会反复执行的一组步骤。

一个最简定义可以写成：

• 读取目标 -> 决定动作 -> 执行动作 -> 观察结果 -> 更新状态 -> 判断是否结束

这就是 Agent 和普通“单次问答”最大的区别之一。

普通问答通常只有：

1. 用户提问
2. 模型回答

而 Agent loop 通常是：

1. 用户给出目标
2. 模型判断是否需要工具
3. 系统执行工具
4. 系统把结果再交给模型
5. 模型判断是否继续
6. 直到任务结束

根据 OpenAI 官方 Running agents 文档在 2026-07-02 可访问的说明：

• 一个 SDK run 本质上是一个应用级 turn
• runner 会不断循环，直到到达真正的停止点

这正是 loop 的核心。

---

2. 为什么 Loop 是 Agent 的核心

如果没有 loop，模型就只能做一次性输出。

但很多真实任务都不是一次完成的，例如：

• 先搜索资料，再总结
• 先读取文件，再决定要不要继续查
• 先提出方案，再调用写入工具执行
• 先把问题分给别的 specialist，再继续处理

这些场景都要求系统具备：

• 持续决策
• 持续执行
• 持续吸收反馈

所以可以说：

• Agent 的灵魂不只是模型，而是 loop

---

3. Loop 解决的根本问题

Loop 主要解决 4 类问题：

3.1 多步任务

任务不是一步完成，而是需要多次判断和动作。

3.2 外部世界交互

系统需要：

• 搜索网页
• 访问数据库
• 读取文件
• 调用 API

3.3 中途调整

Agent 在拿到新结果后，可能发现：

• 信息还不够
• 工具调用失败
• 需要改走另一条路径

3.4 任务完成判定

系统不能只会做动作，还要知道：

• 什么时候该停

---

4. 一个标准的 Agent Loop 长什么样

根据 OpenAI 官方 Running agents 指南在 2026-07-02 可访问的说明，一个典型 loop 可以概括成：

1. 调用当前 agent 的模型
2. 检查模型输出
3. 如果输出了 tool calls，就执行工具并继续
4. 如果发生 handoff，就切换到另一个 specialist 并继续
5. 如果产出了最终答案且没有更多工具工作，就返回结果

这个定义非常值得记住，因为它已经覆盖了现代 Agent 的大多数基本循环。

---

5. 用更通用的方式理解 Loop

如果不绑定具体框架，可以把 loop 写成下面这 6 步：

1. Goal
   • 当前目标是什么
2. Think / Decide
   • 下一步该做什么
3. Act
   • 调工具、走节点、发起 handoff
4. Observe
   • 工具或节点返回了什么
5. Update
   • 状态如何变化
6. Stop or Continue
   • 是否结束

这几乎可以映射到你看到的所有 Agent 框架里。

---

6. Loop 的 7 个核心组成部分

6.1 目标

Loop 必须围绕一个明确目标运行。

例如：

• 回答用户问题
• 生成一份报告
• 完成一项业务处理

如果目标不明确，loop 会表现为：

• 反复做事
• 不知道什么时候停
• 越走越偏

6.2 决策器

通常是模型，也可以是：

• 模型 + 规则
• 分类器 + 模型
• 工作流引擎 + 模型

它负责判断：

• 直接回答，还是先调工具
• 调哪个工具
• 参数是什么
• 是否需要 handoff

6.3 执行器

执行器负责真正把动作做出来。

例如：

• 执行 tool call
• 执行某个 graph node
• 发起数据库查询
• 调用 API

注意：

• 模型只是在“请求动作”
• 真正执行动作的是应用侧执行器

6.4 观察器

观察器负责收集执行结果。

例如：

• 工具是否成功
• 返回了哪些数据
• 是否出现错误
• 是否需要重试

6.5 状态

状态负责记录 loop 当前知道什么。

常见字段：

• 当前轮次
• 已调用工具
• 中间结果
• 错误次数
• 审批状态
• handoff 历史

6.6 终止条件

没有终止条件的 loop 非常危险。

典型终止条件包括：

• 已经有最终答案
• 达到步数上限
• 达到成本上限
• 遇到不可恢复错误
• 等待人工输入

6.7 护栏

Loop 需要护栏，否则：

• 成本会失控
• 风险动作会失控
• 调试会失控

常见护栏：

• 最大步数
• 最大成本
• 超时
• 工具白名单
• 审批节点

---

7. Loop 和工作流的关系

Loop 不等于自由放任的 Agent。

它可以出现在两种系统里：

7.1 动态 Agent Loop

特点：

• 下一步由模型动态决定

适合：

• 搜索
• 研究
• 多工具探索

7.2 固定工作流中的局部 Loop

特点：

• 整体流程固定
• 某个节点内部允许循环

适合：

• 企业流程
• 高可控系统

根据 LangGraph 官方 Workflows and agents 文档在 2026-07-02 可访问的说明：

• workflows 是预设路径
• agents 是动态定义流程和工具使用

所以很多生产系统的现实形态不是二选一，而是：

• 工作流包裹 loop

---

8. 最常见的 5 种 Loop 类型

8.1 工具调用 Loop

形式：

1. 模型输出 tool call
2. 系统执行工具
3. 结果回传模型
4. 模型继续决定

适合：

• 搜索
• 查询
• 文件读取

这是最基础、最常见的一类。

8.2 Planner-Executor Loop

形式：

1. Planner 生成下一步或子任务
2. Executor 执行
3. 根据结果更新计划

适合：

• 复杂调研
• 报告生成
• 多步骤业务任务

8.3 Handoff Loop

形式：

1. 当前 agent 判断自己不最适合处理
2. 把任务交给 specialist
3. specialist 执行后继续 loop

根据 OpenAI 官方 Orchestration and handoffs 文档在 2026-07-02 可访问的说明：

• handoff 的核心价值，在于切换 instructions、models 和 available tools

适合：

• 多角色系统
• 多工具面
• 不同权限域

8.4 Human-in-the-loop

形式：

1. 模型提出动作
2. 系统发现动作需要人工审查
3. 暂停 loop
4. 等待人工决策
5. 再继续或终止

根据 LangChain / LangGraph 的 Human-in-the-loop 文档在 2026-07-02 可访问的说明：

• 当模型建议的动作需要审查时，系统可以 interrupt 并等待决策

适合：

• 写数据库
• 发邮件
• 执行 SQL
• 生产环境操作

8.5 Improvement Loop

形式：

1. 运行 Agent
2. 收集 traces
3. 分析失败
4. 做 eval
5. 改系统
6. 再跑

这是一种更高层的 loop，不是单次执行 loop，而是系统演进 loop。

根据 OpenAI Cookbook 在 2026-07-02 可访问的 Build an Agent Improvement Loop with Traces, Evals, and Codex 示例：

• traces、human/model feedback、evals 可以形成持续改进飞轮

---

9. 一个最小可运行 Loop 示例

可以把最小 loop 理解成下面这段伪代码：

state = init_state(user_goal)

while true:
    model_output = call_model(state)

    if model_output is final_answer:
        return model_output

    if model_output is tool_call:
        tool_result = run_tool(model_output)
        state = update_state(state, tool_result)
        continue

    if model_output is handoff:
        state = switch_agent(state, model_output.target_agent)
        continue

    if exceeded_limits(state):
        return fail_safely(state)

这段结构几乎就是很多 Agent runtime 的核心。

---

10. Loop 为什么会失败

Loop 的失败通常不是单点问题，而是系统问题。

10.1 没有明确结束条件

后果：

• 无限循环
• 重复调同一个工具
• 成本持续上涨

10.2 工具设计太模糊

后果：

• 模型不知道该什么时候调用
• 参数经常填错
• 结果无法稳定回流

10.3 状态设计太弱

后果：

• 模型反复查同样的信息
• 中间结论丢失
• 无法恢复任务

10.4 没有错误恢复策略

后果：

• 一次失败就崩
• 或者盲目重试

10.5 没有权限与审批

后果：

• 高风险动作直接执行

---

11. Loop 的停止条件应该怎么设计

停止条件是 loop 的命门。

建议至少同时具备两类停止条件：

11.1 业务完成型停止条件

例如：

• 已经回答完问题
• 已生成完整报告
• 已完成目标动作

11.2 保护型停止条件

例如：

• 达到最大步数
• 达到超时上限
• 达到成本上限
• 遇到不可恢复错误
• 等待人类审批

一个成熟系统通常两类都要有。

---

12. Loop 中的错误处理策略

一个好的 loop 不只是“能跑”，还要“能失败得体面”。

常见错误处理策略：

12.1 Retry

适合：

• 临时网络失败
• 瞬时 API 错误

12.2 Fallback

适合：

• 主工具失败时，切换到备选工具
• 主模型失败时，降级到更稳的方案

12.3 Ask for Clarification

适合：

• 用户目标不明确
• 参数信息缺失

12.4 Safe Stop

适合：

• 高风险动作无审批
• 达到资源上限
• 多次失败仍无法恢复

---

13. Loop 与状态持久化

短 loop 可以只存在内存里。

但长任务 loop 通常需要持久化：

• 任务暂停后恢复
• 人工审批后继续
• 跨进程继续执行

根据 LangGraph Overview 与 Graph API 文档在 2026-07-02 可访问的说明：

• graph 支持 evolving state over time
• LangGraph 关注 durable execution

这意味着一旦 loop 变长，状态持久化会从“可选”变成“几乎必需”。

---

14. Loop 与可观测性

如果没有 trace，你通常只知道：

• 输入是什么
• 最终输出是什么

但看不到：

• 中间做了多少轮
• 为什么选了某个工具
• 是哪一步出错

所以对 loop 来说，至少要记录：

• step 编号
• 当前 agent
• 当前工具
• 工具参数
• 工具结果
• 状态变化
• 是否触发 handoff
• 是否触发审批

---

15. Loop 与成本控制

Loop 会天然带来成本放大风险，因为每一轮都可能：

• 调一次模型
• 调一次或多次工具

所以你需要显式控制：

• 最大步数
• 最大 token 成本
• 最大工具调用次数
• 最大 wall-clock time

如果这些限制没有明确写出来，loop 非常容易变成“永远能继续”的系统。

---

16. Loop 与提示词的关系

Loop 本身是执行框架，但它的行为很大程度取决于提示词。

特别是在 Agent 场景中，提示词应明确写出：

• 什么时候先回答
• 什么时候先用工具
• 什么时候停止
• 什么时候请求澄清
• 哪些操作必须等待审批

如果提示词没有定义这些原则，loop 往往会表现得：

• 漫无目的
• 过度工具调用
• 或者过早停止

---

17. Loop 在不同框架中的表现

17.1 OpenAI Agents SDK

根据官方文档在 2026-07-02 的可访问说明，SDK 会自动处理一部分 loop 细节，例如：

• tool calls
• multi-turn continuation
• handoffs
• 部分 guardrails 与 orchestration

适合：

• 快速搭建标准 Agent loop

17.2 LangGraph

根据官方文档在 2026-07-02 的可访问说明，LangGraph 更偏底层：

• 你显式定义 nodes
• 显式定义 edges
• 可以构建带循环的 graph
• 重点在持久化、调试、长任务控制

适合：

• 复杂 loop
• 可恢复 loop
• 人工介入 loop

---

18. 判断一个 Loop 是否设计良好的 10 个问题

1. 目标是否明确？
2. 结束条件是否明确？
3. 有没有最大步数？
4. 工具是否清晰、可预测？
5. 状态是否足够支持恢复？
6. 错误处理是否存在？
7. 是否记录 trace？
8. 高风险动作是否需要审批？
9. handoff 规则是否清晰？
10. 成本是否可控？

如果这 10 个问题里有 4 个以上答不清楚，loop 通常还不够工程化。

---

19. 一个现实中的推荐实现顺序

建议按这个顺序实现 loop：

1. 先做单 Agent + 单工具 loop
2. 再做多工具 loop
3. 再加状态
4. 再加错误恢复
5. 再加审批
6. 最后才做 handoff 或 multi-agent

这个顺序的原因很简单：

• 先解决“能跑”
• 再解决“能控”
• 最后解决“能长期稳定运行”

---

20. 常见误区

误区 1：loop 越自由越强

不对。越自由通常越难控。

误区 2：只要能 tool call 就算 loop 设计好了

不对。tool call 只是其中一个动作。

误区 3：只看最终结果，不看中间过程

这样几乎无法调试。

误区 4：把所有复杂度都交给模型

好的 loop 通常是：

• 模型负责决策
• 系统负责约束、执行和记录

误区 5：没有停止条件

这是最危险也最常见的问题。

---

21. 一句话总结

如果要用一句话解释 loop，可以这样说：

• Loop 是 Agent 为完成目标而反复执行“决策 -> 动作 -> 观察 -> 更新 -> 判断是否结束”的运行机制。

---

22. 学完本章后你应该会什么

学完后，你至少应该能：

1. 解释 loop 和单次模型调用的区别
2. 写出一个最小 agent loop 的伪代码
3. 为 loop 设计停止条件
4. 判断什么时候要加审批
5. 识别 loop 的典型失败模式

---

23. 推荐阅读

以下资源在 2026-07-02 检查时可访问：

• OpenAI Agents SDK：https://developers.openai.com/api/docs/guides/agents
• Running agents：https://developers.openai.com/api/docs/guides/agents/running-agents
• Orchestration and handoffs：https://developers.openai.com/api/docs/guides/agents/orchestration
• Building agents：https://developers.openai.com/tracks/building-agents
• LangGraph Workflows and agents：https://docs.langchain.com/oss/python/langgraph/workflows-agents
• LangGraph Overview：https://docs.langchain.com/oss/python/langgraph/overview
• LangGraph Graph API：https://docs.langchain.com/oss/python/langgraph/graph-api
• LangChain Human-in-the-loop：https://docs.langchain.com/oss/python/langchain/human-in-the-loop
• Anthropic Tool use overview：https://docs.anthropic.com/en/docs/build-with-claude/tool-use/overview
• OpenAI Cookbook: Agent Improvement Loop：https://developers.openai.com/cookbook/examples/agents_sdk/agent_improvement_loop